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SECOND SUBSTITUTE SPECIFICATION (CLEAN VERSION) 



A PLUGGABLE SERVICE DELIVERY PLATFORM 



BACKGROUND 
1 . Technical Field 

This invention relates to a service delivery 
platform that supports many devices to access many 
services and more particularly, to a pluggable service 
delivery platform in which many devices and many services 
are pluggable. 



2 . Description of Related Art 

Nowadays there are numerous pervasive computing 
devices such as handheld PCs, smartphone, mobile phone, 
screenphone, pager, fax machine, etc. They all have 

15 computing power and people wish to use these existing 
devices to access the network and do e-business. But 
there also exists challenges, since current network 
infrastructure is designed for the personal computer 
("PC"). At the same time different services have 

20 different features. Thus, some effort is needed to ■ 
connect a new device to the network, if the backend 
system is changed, e.g., if some new service is added, 
the application on the device must be changed (or added) ; 
similar effort is needed to change the logic of backend 
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services when new devices roll out. With the rapid 
development of network computing, there is a need for a 
pluggable service delivery platform that can support many 
devices and many services in a flexible and scalable way. 

Some companies have designed some platforms for 
supporting many devices to access many services, but 
these platforms are designed specifically for some . 
devices and services and there is no flexible way to plug 
a new kind of device or a new type of service into the 
platform. 

SUMMARY OF THE INVENTION 

The pluggable platform of the present invention Can 
be used to overcome the shortcomings of existing 
platforms. The platform can be used in e-business and 
support many kinds of devices to access many types of 
services, while at the same time, new devices or new 
services can be easily added to the platform. This is 
where "pluggable" comes from. 

The pluggable service delivery platform of the 
present invention comprises: 
- Device Abstraction Layer (DAL) 

It accepts the requests from devices and transforms 
them into XML and then sends them to the kernel of the 
platform. It also transforms the response XML documents 
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from the platform into a device specific format for 
presentation ♦ It further comprises: 

(1) Common transcoding component, shared by all devices 
and used for transforming between different kinds of data 
formats. 

(2) Device dependent component, transforming between 
(whatever kind of data f ormat/tranporting protocol for 
that particular device) and (XML over HTTP) . 

- Service Abstraction Layer (SAL) 

It abstracts the common requirements from different 
, services as a service profile. For each kind of service 
in some domain, a wrapper (adapter) is provided. The 
wrapper is used for transforming between (legacy data 
format /network protocol) and (XML/HTTP) . 

- Kernel Service Engine 

The functions provided by the platform kernel 
service engine include : 

- manage profiles of users, devices and services 
(i.e., user/device/service) 

- synchronize/asynchronize service engine 

- interface with other platform components 

- transfer information between components within the 
platform using XML. 

The platform is "pluggable" in three aspects. 
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Firstly, it is pluggable in the sense that a new 
kind of device can be easily plugged into the platform so 
long as the device profile that describes the device 
capability is provided. 

Secondly, it is pluggable in the sense that a new 
type of service can be easily plugged into the platform 
so long as the service profile that describes the service 
feature is provided. 

Thirdly, it is pluggable in the sense that the 
components that constitute the platform are pluggable, so 
'any one of the components can be replaced by third party 
products, so long as the latter comply with a predefined 
interface, such as a Java Servlet and LDAP. 

. The differences between the platform of this 
invention and an exemplary existing platform is listed in 
Table 1. A local network company had the similar idea of 
a many- to-many platform called LISP/6A. 
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TABLE 1 



Features 


LISP/6A 


This platform 


Transcoding 


No. Format has to be 
customized for each 
kind of device 


Yes. The same 
content can be 
adapted to 
different kind of 
PvC devices 


Scalability 


No 


Yes. With Network 
Dispatcher & Web 
Traffic Express' & 
Distributed 
Application Tester 


Contents 

representation in 
platform 


Fixed segments with 
annotation 


Represented in XML, 
easy to be extended 


Support 

synchronized and 

asynchronized 

communication 


No 


Yes 


Flexibility for 
plug in new 
device 


No 


Yes 


Flexibility for 
plug in new 
service 


No 


Yes 


Component i zed 
parts within 
platform 


No 


Yes 
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BRIEF DESCRIPTION OF THE DRAWINGS 

FIG. 1 shows a preferred embodiment of a pluggable 
service delivery platform, which focuses on components of 
a platform kernel. 

FIG. 2 shows the servlet (service engine) running on 
WebSphere (an IBM Web application server) . 

FIG. 3 shows the data flow between the service 
engine and the backend service (such as stock service) . 

FIG. 4 shows the device abstraction layer 
(device-platform interface) of the pluggable service 
-delivery platform of Fig. 1. 

FIG. 5 shows the service abstraction layer 
(platform- service interface) of the pluggable service 
delivery platform of Fig. 1. 

FIG. 6 shows an implementation of the present 
invention using a WAP phone to access services through 
the platform. 

FIG. 7 shows the process of adding a new kind of 
device to the platform. 

FIG. 8 shows the process of adding a new type of 
service to the platform. 
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DETAILED DESCRIPTION OF PREFERRED EMBODIMENTS 

It is to be understood that the exemplary system 
modules and method steps described herein may be 
implemented in various forms of hardware, software, 
5 firmware, special purpose processors, or a combination 

thereof. Preferably, the present invention is implemented 
in software as an application program tangibly embodied 
on one or more program storage devices. The application 
program may be executed by any machine, device or 

10 platform comprising suitable architecture. It is to be 

further understood that, because some of the constituent 
system modules and method steps depicted in the 
accompanying Figures are preferably implemented in 
software, the actual connections between the system 

15 components (or the process steps) may differ depending 
upon the manner in which the present invention is 
programmed. Given the teachings herein, one of ordinary 
skill in the related art will be able to contemplate 
these and similar implementations or configurations of 

20 the present invention. 

Before describing preferred embodiments in detail, 
the terms used in the present invention are first listed 
'as follows: 
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TERMS USED : 

1. XML (extensible Markup Language) : XML is a kind of 
markup language endorsed by W3C (Web standard 
organization) . It is used to describe/define structured 

5 data and separate the data with presentation (compared 
with HTML which strongly combines data and the 
presentation) . The same set of data expressed by XML 
language can generate a different presentation (e.g./ 
Markup Language) with a different style sheet language 

10 (e.g., XSL: extensible Stylesheet Language). 

Highly- structured data represented in XML are very 
suitable for automatically exchanging information between 
applications. The adoption of XML for exchange between 
different components is a primary characteristic of the 

15 present invention. 

2. WAP (Wireless Application Protocol): WAP is a wireless 
communication protocol specifically designed for handheld 
devices (especially mobile phones) . WAP is critical for 
mobile phones to access the information on the Internet 

20 just as HTML/HTTP is critical for a to access the 
Internet . 

3. Servlet: Servlet is a Java small service application,, 
i.e., a special kind of Java class running on a Web 
server. It can accept the request from the Web (e.g., via 

25 a browser) , parse the parameters and execute the 

predefined logic (such as a data connection with the 
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backend system) and generate a response and send the 
response back to the browser. Since Java Servlets are 
written in Java they are cross platform (OS) and highly 
portable applications. Java servlet can dynamically 
5 generate different pages for different kinds of devices 
such as HTML for PC, WML for WAP phone, etc. 

4. Trancoding: Transcoding is a kind of transformation 
technique that transforms the same set of data into 
different pages based on predefined criteria (such as 

10 display resolution, color depth, multimedia support) . The 
technique further includes many components, such as an 
image transcoder (e.g., GIF -> JPEG, JPEG -> BMP, color 
-> grey -> black/white) and a text transcoder (e.g., text 
abstraction, text -> audio) . Using a transcoding 

15 technique, one type of XML document can be transformed 
into another type of XML document and can further be 
transformed into some kind of presentation (e.g. HTML or 
WML) by style sheet language. 

5. Device gateway: The device gateway in the present 

20 invention sits in the device abstraction layer. It can 
accept a request from a device over some sort of network 
protocol, transform the request into XML over HTTP, then 
send the request to the platform kernel. After getting 
the data from the backend system through the platform 

25 kernel, the device gateway then transforms the pagre into 
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a device readable page and sends the page to the device 
over the network. 

6. Service adapter (wrapper): The service adapter in the 
present invention sits in the service abstraction layer. 
It transforms between the platform format 
(XML) /protocol (HTTP) and service specific 
format/protocol. 

The following paragraphs will illustrate in detail 
how to implement the invention. 

The pluggable service delivery platform shown in 
FIG. 1 comprises three parts, Device Abstraction Layer 
'(DAL), Service Abstraction Layer (SAL) and Kernel Service 
Engine. FIG. 1 focuses on components of a platform 
kernel. The details of SAL and DAL will be illustrated in 
FIG. 4 and FIG. 5 respectively. As shown in FIG. 1, the 
platform kernel comprises a service engine 101, a runtime 
monitor 102, a profile manager 103 and auxiliary 
components 104 (such as a billing manager 104a, a 
security manager 104b, etc.) As shown in FIG. 1, XML is 
used within the platform as an interface language. XML is 
.used widely in the platform to exchange information 
between different components in the platform. XML is also 
used in the DAL and SAL, such that information processed 
in the platform will be based on XML. For the service 
engine, both a synchronized service engine and an 
asynchronized service engine are provided. For example, 
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the synchronized service engine can be based on IBM 
WebSphere which is a Web application server and has 
strong XML support. 

FIG. 2 shows how servlets are organized in 
WebSphere. As shown, servlets are built on and managed by 
WebSphere (start, stop, add, delete) . A chain of servlets 
can be called when a request from the device is sent to 
the platform. The platform may process the request and 
respond with a page. The first servlet called, which is 
also the most important one, corresponds to a called URL. 
The servlet can then call other servlets which form a 
servlet chain. As shown in FIG. 2, under the WebSphere 
application server (Default Server) , there is a 
ServletEngine which is the base Servlet engine. Under 
ServletEngine there are many directories, such as 
"default_app" , "admin", "examples", etc. Under some 
specific application, there are some servlets that will 
be used. For example, under "def ault_app" , there are 
"Snoop" servlet, "hello" servlet, "ErrorReporter" 
servlet, etc . 

FIG. 3 shows the data chart and also the interaction 
between the service engine and the backend service (e.g. 
stock service) . 

The platform runtime monitor 102 is used to monitor 
,the runtime status of platform. 
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The profile manager 103 is used to manage a user 
profile, device profile and service profile. 

The user profile can include items such as, user ID, 
user name, telephone number, etc. 
5 The device profile can include items such as, device 

ID, vendor name, device type, display resolution, 
multimedia capability, and corresponding XSL (which is 
used to present XML data on that specific device) . 

The service profile can include items such as, 
10 service ID, service provider, operating time, start URL, 
etc. 

Besides the above components, the platform kernel 
can also include many auxiliary components, such as a 
device manager to manage device access, a service manager 

15 to manage service connection to the platform, an event 
manager to trigger some platform related event and .send 
to user, a transaction manager, a billing manager, and a 
security manager. All the above components are pluggable 
and can be replaced by third party products. 

20 ■ ■ In FIGS. 1-3, the kernel parts of the platform are 

described in detail. These components are used to manage 
user/device/service profile information, provide a 
synchronized/asynchronized service engine, use XML to 
exchange information, and carry transaction related 

25 information between different parts of the platform. As 
shown in, FIG. 1, the platform kernel includes three 
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.layers: a runtime layer, an admin layer and a development 
layer. Platform APIs are used to interact between layers. 
The runtime layer provides online information access and 
control, the management layer provides service such as 
5 add/delete user /device/service information, and the 
development layer provides support for a new 
device/ service . 

In FIG. 4 SAL will be described in detail. 

There are mainly two portions in FIG. 4. The first 

10 portion, on top of the dotted line, is what we call the 
Control mode. The administrator can use the user 
interface ("UI" ) under this mode to install new services 
and configure the existing services. Both the control 
mode portion and run-time mode portion have a PnP (plug 

15 'and play) manager. The enumeration layer, as shown in 
Figure 4, is used to abstract the common features of 
different services and differentiate them by different 
company. The second portion, under the dotted line, is 
what we call the Run- time mode and has mainly three 

20 layers. The bottom layer is the enumeration. Specific 

companies may have its specific drivers which should obey 
the open service protocol. The middle layer is the 
Service Abstract Layer (SAL) . SAL abstracts the common 
.requirement of different services. The upper layer is the 

25 kernel of the run-rime mode and is called the run-time 
unit. It further comprises several important parts. The 
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first one and the most important one is the PnP manager 
that corresponds to the PnP manager in the Control mode 
portion. It has an event listener to listen to events 
coming from the service-platform interface. It manages 
5 the plugged services to the platform. Then there is the 
maintenance manager. The maintenance manager is used to 
manage the lifetime of a service like when it is opened 
and closed, when it will expire, etc. The third one is 
the resource manager. Then there is the security manager 

10 to manage the security in the platform to securely 

transfer messaged and documents. The total service design 
architecture is EVENT DRIVEN and STATE BASED. The 
relationship between different layers is like this. The 
, Service Abstract Layer maintain and administrate services 

15 and report events to the run-time unit. It also works 
with the run-time unit to manage transactions to make, 
sure that several commands from one transaction will not 
be broken into pieces . The main event types include a New 
'service event, an Update event, etc. All the events are 

20 related to service-platform interaction and platform 
operation. 

In FIG. 5 DAL will be described in detail. 

There are also two parts in FIG. 5. The one above 
the dashed line includes Profile Generating Tools to 
25 generate a profile for some new device. The informatipn 
will be saved in the registry and can be accessed by the 
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profile manager of the administrator UI . The other part 
under the dashed line includes a Device Abstract Layer, a 
Profile Manager, and Run-time managers. The run-time 
managers then include a Protocol manager, a Connection 
5 manager, a Contents manager and an event manager. A 

common interface (Device Abstract Layer) is needed to 
define the common behavior of PvC devices. The devices 
may connect to the platform in different ways (e.g. 
LAN/WAN, PSTN, GSM/ CDMA and CDPD) , so gateways are needed 1 
10 for each kind of connection. No matter how the device is 
connected to the platform, the devices 1 rich features can 
be extended from this common base. And this common base 
is expressed in XML too. The profile managers serve as 

» 

'the focal point between the platform device administrator 
15 and the platform run-time kernel. The features of the 

device are saved in the registry as (key, value) pairs. 
Protocol manager is used to decide whether to send the 
message through IP or HTTP protocol in the platform. The 
connection manager is used to manage the connection in a 
20 transaction, e.g., set up the connection in response to a 
device request, send a message when certain conditions 
meet, etc. The contents manager is built upon the 
transcoding technique. It decides how to send out the 
message. It assembles the contents based on the devices' 
25 profile. The event manager generates system events whfen a 
device contacts the platform. (A certain profile header 
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should be provided in the head of the message that the 
device sends) . No matter how the device accesses the 
platform (through GSM, CDPD, PSTN, LAN or other ways), a 
description of the device (profile) must be included in 
5 the header of the message the device sends to the 
platform when the device is logged on. 

In the above paragraphs, a preferred embodiment of a 
pluggable platform according to the present invention is 
illustrated. The platform has the following advantages: 

10 ho matter what kind of device the end users use they can 
always access the key information in a consistent and 
natural way and all the returned pages will fit well on 
'that device. This also simplifies the service connection 
process. For now, the service providers need only one 

15 . reserved line to connect the service to the service 
delivery platform. 

FIG. 6 shows how a service can be hosted on the ■ 
platform. To be specific, the process of using a WAP 
phone to access the services through the platform is 

20 shown. Firstly, various WAP phones connect to the WAP 
gateway through a GSM network and then data channels 
,(PSTN connection or ISDN connection). The information 
before WAP gateway is binary WML over WAP, while after 
the WAP gateway, will be WML over HTTP. When a user uses 

25 the WAP phone, some URL has actually been selected, and 

the request will be sent to a servlet that corresponds to 
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the URL. The servlet will analyze the request parameter, 
call some service wrapper as required, then get data from 
background services. This kind of data connection is 
common to domain service and independent of the specific 
service provider. After getting the data, the servlet 
will reorganize the data and generate a page (e.g. HTML 
or WML) . The page can be generated by transcoding means 
after retrieving the device style sheet (XSL) stored in 
device profile through LDAP call. 

FIG. 7 shows how to plug a new kind of device;. When 
adding a new kind of device, the system administrator can 
,use the admin tools and select "Add New Device" item, and 
then fill in a form to generate a device profile in the 
profile manager. Among the description, XSL is used to 
describe device capability. At the runtime, when the 
platform receives user requests, on one hand, it will 
generate XML data based on the return from service, and 
on the other hand, it will retrieve the device profile 
from the profile manager, then generate the final page 
layout based on the transcoding technique. 

FIG. 8 shows how to plug a new kind of service. When 
adding a new kind of service the system administrator can 
use the admin tools and select "Add New Service" item, 
then fill in a form to generate a service profile in the 
profile manager. At the runtime, when the user connects 
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to the platform, only a dynamic service list that the 
user subscribes will be listed. 

Although illustrative embodiments of the present 
invention have been described herein with reference to 
5 the accompanying drawings, it is to be understood that 
the present invention is not limited to those precise 
embodiments, and that various other changes and 
modifications may be affected therein by one skilled in 
the art without departing from the scope or spirit of the 
10 invention. All such changes and modifications are 

intended to be included within the scope of the invention 
as defined by the appended claims. 
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